home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 208 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.9 KB
  1. Date: Wed, 1 Jun 94 11:10 BST-1
  2. From: Ofir Gal <ogal@cix.compulink.co.uk>
  3. Subject: Re: Proposal
  4. To: gem-list@world.std.com
  5. Message-Id: <memo.260144@cix.compulink.co.uk>
  6. Precedence: bulk
  7.  
  8.  
  9. In-Reply-To: <199406010806.KAA19392@blade.stack.urc.tue.nl>
  10.  
  11.  
  12. >I don't like it that almost any key has been given away already. That is
  13. >one reason I want to see fewer short-cuts in the proposal. Another
  14. >reason is that a program that wants to support all these short-cuts in
  15. >menus will have LARGE menus. Anyway, what I think is a better solution
  16. >is to have a backward/forward radiobuttonblock in the CTRL F (find)
  17. >dialog. That way one can save some menu space and keyboardshortcuts.
  18.  
  19. Let me change my mind, this makes more sense than a specific key for
  20. find previous.
  21.  
  22. >I don't like 'light'. I think this has to do with the weight of a
  23.  
  24. Me neither.
  25.  
  26.  
  27. >As with all these short-cuts, I think that these are merely guidelines,
  28. >which you use should you provide a function, so there is nu MUST provide
  29. >for this function I think.
  30.  
  31. Exactly, you should only provide the keyboard shortcuts if they are useful
  32. in your program.
  33.  
  34. >Agreed, I think we do need some standard here too. Maybe we should
  35. >suggest that the minimizer is only for non-modal dialogs, and that
  36. >dialogs never have the fuller and scroll-bar. I really dislike some
  37. >programs that were written with 640*480 in mind, that give me scrollbars
  38. >to move through the dialog on my 640*400 screen. Maybe it would be a
  39. >good recommendation to limit dialogs to 320 pixels in the vertical
  40. >direction.
  41.  
  42. I agree.
  43.  
  44. >I like the idea of moving to first and last field. Maybe we can use the
  45. >same keys here as Atari prescribed for cursor movement, like shift
  46. >downarrow for last field and shift uparrow for first field. BTW what is
  47. >EGEM? Is it a library? Is it available as source, and can it be compiled
  48. >with Sozobon C? (a private reply will do fine, not everyone may be
  49. >interested).
  50.  
  51. Yes. My toolkit currently supports:
  52.  
  53. ClrHome -                jump to first editable field
  54. Shift+ClrHome -          jump to last editable field
  55. Tab or down arrow -      move one field forward with wrap
  56. Shift+Tab or up arrow -  move one field back with wrap
  57. Shift+left arrow -       move to start of field
  58. Shift+right arrow -      move to end of field
  59. Control+left -           move back one word
  60. Control+right -          move forward one word
  61. Control+Delete -         delete text from cursor position
  62. Control+Backspace -      delete text up to cursor
  63. Shift+Insert -           Display ASCII table.
  64.  
  65. Some of these will have to change to follow the new guidelines, but the
  66. principle applies. These are based on Let 'em Fly which will have to
  67. change as well. Luckily, development of V2 is currently taking place and
  68. the developers are on this list.
  69.  
  70. >Agreed. And maybe we should recommend the use of a standard font
  71. >selector (like the UFSL) if one is available.
  72.  
  73. What is UFSL?
  74.  
  75. Bye,
  76.  
  77. Ofir                                    ogal@cix.compulink.co.uk
  78.  
  79.